多年來，IT 監控以各種方式被應用和部署。其核心目的是收集有關不只是 IT 基礎設施以及雲原生服務的硬體和軟體運作指標，確保所有關鍵功能都能順利運作，進而維護應用程式和 IT 服務的品質。
近年來，「可觀測性」這一術語越來越受到關注，被視為是「新一代的監控」。接下來，我們將探討什麼是可觀測性、它與傳統監控的差異，以及實施可觀測性所需的關鍵元素。
有人說：喔！可觀測性的出現只是為了應付 RD 們對於監控的厭倦而另外包裝出來的漂亮糖衣，就像原本的 Ops 又延伸出 DevOps 甚至 DevSecOps 等新潮名詞，直到榨乾我們最後一絲腦力。
在各種行業中特別是軟體業，隨著網路的活絡以及科技日益越進，每天都有推層出新的概念以及名詞出現。久而久之，大夥對於聽到新事物時，反而第一時間都是習以為常的半開玩笑，戲謔的口吻說著學不動了，但滑鼠依然不受控制地打開 Github 查看文件。
在過去二十年中，監控是工程師的職責，對於許多從事這行業許久的人，總多少代表著些不太愉快的回憶，但因為當時傳統的系統架構通常使用單體式服務和一種語言建構而成，複雜度不大且版本迭代可能數個月才會發佈一次。
而現在應用服務與傳統應用服務有很大的不同。不止是單體式與微服務的差別，使用容器、Kubernetes 等雲原生技術與多種程式語言，編排成一個完整的複雜服務。並且擁抱更多的自動化像是 Infrastructure as Code（IaC）以及其他編排機制下的自動部署，再加上 DevOps 的技術文化成熟，帶來更輕量更頻繁的迭代頻率，這其中除了系統的複雜交互溝通，更考驗多個部門團隊的協作能力。
雖然現代應用技術提供了我們敏捷性、可擴展性的彈性，並允許快速導入或修正錯誤的能力，但他們明顯增加了複雜性，帶來非常沉重的業務邏輯跟維護成本。有鑒於現代應用服務對於當今企業的重要性，每次發生故障導致服務異常，可能就會對企業帶來數十萬的收入損失。因此，人們開始意識到這個問題的嚴重並紛紛開始提出解決方案，不止要知道何時出現問題，還必須能快速定位問題原因，並且迅速反應修正，這才有後來我們耳熟能詳的『可觀測性 Observability』的誕生。
在權威機構 DORA（DevOps Research and Assessment）的研究定義了以下術語：
簡單來說，監控可以告訴你什麼時候出現了問題，而可觀測性可以告訴你為什麼出現問題。
雖然監控僅限於在 IT 系統中發生性能、使用或可用性變化（即發生異常）時通知您，但可觀察性提供了必要的詳細信息，讓您了解發生此變化的原因。思考差異的一種方法是將監控視為收集指標，將可觀察性視為提供分析收集的指標並確定需要採取哪些行動來緩解問題所需的情報和分析。
在監控方面通常從三個層面來衡量：
其中應用服務的指標通常是三者中變化最大也是最重要的，儘管傳統的監控服務已經證明，他們依然非常完善健全，但依然得隨著時代的腳步前進。
而大部分的人認為可觀測性仰賴著三種指標，以幫助我們實現可視化：
Ｍetrics、Logs、Traces 通常被人稱之為可觀測性三本柱，這些數據類型在雲原生可觀測性上發揮著至關重要的作用，每個支柱都提供了組織資源的不同視角。當這些數據源重新被組合和分析可視化時，團隊就可以一窺複雜的應用服務中發生的情況。
監控最適合報告系統的整體健康狀況。旨在『監控一切』可能被證明是一種反模式。因此，監控最好僅限於源自基於時間序列的儀器、已知故障模式以及關鍵業務和系統指標。另一方面，“可觀察性”旨在提供對系統行為的高度精細的洞察以及豐富的上下文，非常適合除錯目的。由於仍然不可能預測系統可能遇到的每種故障模式或預測系統可能出現故障的每種可能方式，因此我們構建可以根據證據而不是猜測進行調試的系統變得很重要。
在下篇文章中，我們就來深入了解所謂的可觀測性三本柱在實際服務中扮演的角色吧！
在接觸了 Kubernetes 後的小弟，確實經歷如同時代縮影般的從單體式應用投入到微服務，同時也體會到別人說在微服務裡做相同的一個功能會比在單體式架構多了指數倍的難度，微服務的彈性就像是一把雙面刃，大家用的好帶你上天堂，一人用不好就帶團隊下地獄的窘境，但我們都知道工程師的價值在於解決困難的問題，越危險的地方風景越迷人，所以我們還有什麼不投入這個可觀測性世界的理由嗎！
相關程式碼同步收錄在：
https://github.com/MikeHsu0618/grafana-stack-in-kubernetes/tree/main/day3
References
DevOps 衡量：监控和可观测性 | 云架构中心 | Google Cloud
The 3 pillars of observability: Logs, metrics and traces | TechTarget
iThome鐵人賽
看影片追技術